Attacking certificate authorities

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Feb 26, 2008.

  1. I've just been setting up a custom SSL certificate authority for a client,
    so that their users can do things like securely access their mail on the
    IMAP server from home. Each user has to import the CA cert into their
    machine somehow, whereupon it will trust any certs signed by that CA, such
    as the one installed into the IMAP server.

    The procedure for doing this import varies a lot from system to system. When
    I was trying it with Thunderbird under Linux, I was adding it only to the
    CA certs trusted by Thunderbird, not by Firefox or anyone else. A client
    using a Mac had to add it to their systemwide keychain, and I'm not sure
    what kind of restrictions they could put on that certificate.

    But if this CA cert were trusted systemwide, it could open the user's system
    to vulnerabilities. For instance, if someone were to break into our server
    and grab the key for that cert, they could then sign other certs which
    would be accepted as valid by the user's system. If they used the same
    machine for online banking, they could unknowingly be vulnerable to a
    phishing attack, which would only be revealed by careful checking of the
    site's certificate details.

    The only way to prevent this is to be able to impose restrictions on which
    apps will trust that CA cert and for what, as on the Linux system.

    Thoughts, anyone?
    Lawrence D'Oliveiro, Feb 26, 2008
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    EMB Guest

    Lawrence D'Oliveiro wrote:
    > I've just been setting up a custom SSL certificate authority for a client,
    > so that their users can do things like securely access their mail on the
    > IMAP server from home. Each user has to import the CA cert into their
    > machine somehow, whereupon it will trust any certs signed by that CA, such
    > as the one installed into the IMAP server.


    Why not just use a cert from one of the public trusted CAs? For the
    sake of a few dollars it's not worth the pissing about issuing your own
    certs.
    EMB, Feb 26, 2008
    #2
    1. Advertising

  3. Lawrence D'Oliveiro

    Enkidu Guest

    Lawrence D'Oliveiro wrote:
    > I've just been setting up a custom SSL certificate authority for a client,
    > so that their users can do things like securely access their mail on the
    > IMAP server from home. Each user has to import the CA cert into their
    > machine somehow, whereupon it will trust any certs signed by that CA, such
    > as the one installed into the IMAP server.
    >
    > The procedure for doing this import varies a lot from system to system. When
    > I was trying it with Thunderbird under Linux, I was adding it only to the
    > CA certs trusted by Thunderbird, not by Firefox or anyone else. A client
    > using a Mac had to add it to their systemwide keychain, and I'm not sure
    > what kind of restrictions they could put on that certificate.
    >
    > But if this CA cert were trusted systemwide, it could open the user's system
    > to vulnerabilities. For instance, if someone were to break into our server
    > and grab the key for that cert, they could then sign other certs which
    > would be accepted as valid by the user's system. If they used the same
    > machine for online banking, they could unknowingly be vulnerable to a
    > phishing attack, which would only be revealed by careful checking of the
    > site's certificate details.
    >
    > The only way to prevent this is to be able to impose restrictions on which
    > apps will trust that CA cert and for what, as on the Linux system.
    >
    > Thoughts, anyone?
    >

    I think that the recommended way of doing that is to backup the key and
    *remove it* from the system. If you want to sign another certificate you
    restore the key, then delete it when finished. The key should not be
    permanently on the CA or accessible to it over the network.

    Cheers,

    Cliff

    --

    Have you ever noticed that if something is advertised as 'amusing' or
    'hilarious', it usually isn't?
    Enkidu, Feb 26, 2008
    #3
  4. In article <47c3e576$>, Enkidu did write:

    > I think that the recommended way of doing that is to backup the key and
    > *remove it* from the system. If you want to sign another certificate you
    > restore the key, then delete it when finished. The key should not be
    > permanently on the CA or accessible to it over the network.


    I can see the point in that in a high-security application, but this is not.
    My point was about whether the simple presence of a low-security CA cert on
    a user's machine can lower the security of checking all certs by that
    machine.
    Lawrence D'Oliveiro, Feb 27, 2008
    #4
  5. Lawrence D'Oliveiro

    EMB Guest

    Lawrence D'Oliveiro wrote:
    > I can see the point in that in a high-security application, but this is not.
    > My point was about whether the simple presence of a low-security CA cert on
    > a user's machine can lower the security of checking all certs by that
    > machine.


    Is not a 'low-security CA cert' an oxymoron.
    EMB, Feb 27, 2008
    #5
  6. Lawrence D'Oliveiro

    thingy Guest

    Lawrence D'Oliveiro wrote:
    > I've just been setting up a custom SSL certificate authority for a client,
    > so that their users can do things like securely access their mail on the
    > IMAP server from home.


    yep, I do this....

    Each user has to import the CA cert into their
    > machine somehow, whereupon it will trust any certs signed by that CA, such
    > as the one installed into the IMAP server.


    When they first connect it should ask to accept permanently
    (Thunderbird)...but self certs seem "worse" on IE and the mac email
    client...they dont seem to permanently accept a self-cert....can this be
    done?

    > The procedure for doing this import varies a lot from system to system. When
    > I was trying it with Thunderbird under Linux, I was adding it only to the
    > CA certs trusted by Thunderbird, not by Firefox or anyone else.


    Yes.

    A client
    > using a Mac had to add it to their systemwide keychain, and I'm not sure
    > what kind of restrictions they could put on that certificate.
    >
    > But if this CA cert were trusted systemwide, it could open the user's system
    > to vulnerabilities. For instance, if someone were to break into our server
    > and grab the key for that cert, they could then sign other certs which
    > would be accepted as valid by the user's system. If they used the same
    > machine for online banking, they could unknowingly be vulnerable to a
    > phishing attack, which would only be revealed by careful checking of the
    > site's certificate details.


    A bit exotic but yes...and how many people do you know that could check
    a cert and be 100% confident its real?

    > The only way to prevent this is to be able to impose restrictions on which
    > apps will trust that CA cert and for what, as on the Linux system.
    >
    > Thoughts, anyone?


    Not sure what you are getting at here, you can choose to only accept the
    certificate for a temporary session, so nothing gets added permanently
    to your keychain, if you are that paranoid....

    You only accept a cert per "remote site" so you could not use a trademe
    cert to replace an "ASB" cert? i would suppose you need to set up a
    trial instance and test your hypothesis.

    I would think the Mac's keychain would be bright enough to only allow
    that cert with that particular application....certainly this is the
    observed case on XP, ie when I test IE7 and Firefox on webmin's ssl cert
    for instance both ask what to do.

    You can go into a Macs keychain module and "fiddle" with it, I have had
    to trying to get secure LDAP working....it is not fun....

    regards

    Thing
    thingy, Feb 27, 2008
    #6
  7. In article <47c56f65$>, EMB did write:

    > Lawrence D'Oliveiro wrote:
    >
    >> I can see the point in that in a high-security application, but this is
    >> not. My point was about whether the simple presence of a low-security CA
    >> cert on a user's machine can lower the security of checking all certs by
    >> that machine.

    >
    > Is not a 'low-security CA cert' an oxymoron.


    Why should it be? There are different degrees of security, depending on the
    value of what you're trying to protect, and what sorts of potential threat
    scenarios you envisage.
    Lawrence D'Oliveiro, Feb 27, 2008
    #7
  8. In article <>, thingy did write:

    > Not sure what you are getting at here, you can choose to only accept the
    > certificate for a temporary session, so nothing gets added permanently
    > to your keychain, if you are that paranoid....


    I think you're talking about self-signed certificates, which is not quite
    the same thing as CA certs, also known as "root" certs. The latter are the
    ones the SSL clients have to take on trust to begin with, and which are
    used to sign the actual site certs.
    Lawrence D'Oliveiro, Feb 28, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Holdoway

    Is someone attacking my pix??

    Steve Holdoway, Jul 25, 2003, in forum: Cisco
    Replies:
    0
    Views:
    388
    Steve Holdoway
    Jul 25, 2003
  2. JohnNews

    Attacking the CCNP Mountain

    JohnNews, Oct 14, 2003, in forum: Cisco
    Replies:
    3
    Views:
    519
    Jason Whiteaker
    Oct 14, 2003
  3. William J King
    Replies:
    1
    Views:
    385
    Walter Roberson
    Dec 17, 2003
  4. Ron

    Is Microsoft Attacking?

    Ron, Nov 22, 2005, in forum: Computer Security
    Replies:
    3
    Views:
    432
    David H. Lipman
    Nov 22, 2005
  5. Au79
    Replies:
    2
    Views:
    497
    wisdomkiller & pain
    Sep 6, 2007
Loading...

Share This Page