Gov't coerced Certs thwart SSL/TLS

Discussion in 'Computer Security' started by nemo_outis, Mar 29, 2010.

  1. nemo_outis

    nemo_outis Guest

    nemo_outis, Mar 29, 2010
    #1
    1. Advertising

  2. nemo_outis

    Nomen Nescio Guest

    >Researchers at Indiana University opine that CA-issuers may be co-opted and
    >coerced to improperly issue SSL certificates.


    >Has SSL become pointless? Researchers suspect state-sponsored CA forgery
    >http://www.betanews.com/article/Has-SSL-become-pointless-Researchers-
    >suspect-statesponsored-CA-forgery/1269551694


    >Original paper here:


    >Certified Lies: Detecting and Defeating Government
    >Interception Attacks Against SSL
    >http://files.cloudprivacy.net/ssl-mitm.pdf


    This was very interesting. And I don't doubt that the government
    might be pressuring the cert companies to issue bogus certs.

    I loved the statement:
    'Other contributors agreed there may not be due cause to withdraw
    CNNIC (China cert authority) from Firefox's root store, until
    specific evidence of claims such as this one emerges.'

    Do they actually think that dead men are going to be able to
    make claims?
     
    Nomen Nescio, Mar 29, 2010
    #2
    1. Advertising

  3. It would seem that the best protection against governmemt intrusion
    into certs is for companies to self issue their own certs and carry
    them to the cert companies.


    Il mittente di questo messaggio|The sender address of this
    non corrisponde ad un utente |message is not related to a real
    reale ma all'indirizzo fittizio|person but to a fake address of an
    di un sistema anonimizzatore |anonymous system
    Per maggiori informazioni |For more info
    https://www.mixmaster.it
     
    George Orwell, Mar 29, 2010
    #3
  4. nemo_outis

    Guest Guest

    In article <>,
    says...
    > It would seem that the best protection against governmemt intrusion
    > into certs is for companies to self issue their own certs and carry
    > them to the cert companies.
    >
    >

    I think the problem with that is that anyone can generate a certificate
    for any company, i.e. anyone could certainly generate a certificate that
    indicated they were the Bank of America. What makes it impossible to
    use is that a check with a Certificate Authority such as VeriSign would
    indicate it was not genuine. If Bank of America generated one of their
    own they could certainly give it to VeriSign to distribute but they
    would still be dependent on VeriSign to indicate that it was genuine and
    actually came from Bank of America before it could be used. Given that,
    what would stop a third party from generating a certificate indicating
    that they also were Bank of America and forcing VeriSign under duress to
    indicate that this alternate certificate was genuine as well?

    The bottom line is that you have to trust the source of the certificate
    regardless of who generates it. If that trust is gone the certificate
    is pretty much useless.

    Unfortunately I do not see a solution. As long as there are
    organizations with more clout or means of persuasion than the authority
    vouching for the authenticity of the certificate, the certificate is
    suspect.

    At least that is the way I see it but I am not an expert. If someone
    sees an error in my thinking, I am willing to listen.
     
    Guest, Mar 30, 2010
    #4
  5. nemo_outis

    nemo_outis Guest

    George Orwell <> wrote in
    news::

    > It would seem that the best protection against governmemt intrusion
    > into certs is for companies to self issue their own certs and carry
    > them to the cert companies.



    I will answer you and afterwards I'll explain in a postscript a different
    CA attack from the one in the articles that is very serious and very easy
    to do!


    As matters currently stand companies DO *generate* their own certs (or
    call it a pre-cert if you will). The CAs (e.g., Verisign) merely
    *digitally sign* those pre-certs (using as much or as little due
    diligence as they see fit to confirm their provenance) thereby converting
    them to "certified" certificates (to make a weak joke).

    Alternatively, a company (or other entity, such as you or me) can perform
    *both* the generation and certifying roles - this results in a "self-
    signed" certificate. Such a certificate effectively says: "I hereby
    certify that I am me."

    Fortunately, there is no way to forge/spoof the company public/private
    key part of either a CA-signed or self-signed certificate (without
    breaching the original company's internal security); that part of the
    protocol is rock-solid. The public/private keypair guarantees that an
    entity, whether counterfeit or genuine, can at least be confirmed to be
    the *same* entity at some later time. Any spoofing of an entity (even
    one signed by a corrupt cert authority) must use different company keys
    on the cert (that is, if the corrupt party expects to be able to decrypt
    the SSL signon).

    Surprisingly, the self-signed certificate is the *best* type of
    certificate *from a security standpoint* precisely because it does appear
    so weak (a paradox, a paradox, a most ingenious paradox...). All
    browsers will immediately flag such a "cert" for you rather than "rubber
    stamp" it as OK and such a cert obviously requires further scrutiny if
    the site involves any degree of trust in your dealings with it (which,
    however, *isn't* always the case).

    So, how do you check out whether a self-signed cert is valid? There are
    a number of methods but the short version is: By contacting the company
    (or some other entity that is both trustworthy and knowledgable about the
    company's cert) to confirm the validity of the company's cert.

    However, as they say in the late night TV ads, "But wait! There's more!"
    You should contact the company (or other trustworthy entity) either
    directly (i.e., face-to-face) or at least using an "out-of-band"
    communication path (i.e., not the same as the initial one where you first
    encountered the cert). But in this case you could have simply got the
    cert here originally and not just as confirmation after getting it by a
    less trustworthy path.

    Incidentally, the problem with using some "other trustworthy entity"
    instead of the company itself is that that is exactly what the CA tried
    to be (and failed). Except in special circumstances, why would you expect
    some other entity performing a similar role (e.g., the repository in the
    "perspectives" add-on) to be any better?

    So, while the self-signed cert is the *best* from a security standpoint,
    it *stinks* from a usability standpoint. Besides being a PITA for you to
    do this, few companies, except maybe some banks, are set up to handle it
    (e.g., a telephone inquiry). Moreover, the website traffic would dwindle
    to near nothing because most users would be neither capable nor willing
    to go to such trouble.

    Probably the best from a compromise viewpoint for companies with at least
    moderately skilled, privacy-conscious users (i.e, the 7 of us :) is to
    have some automated out-of-band way of checking its cert (by telephone,
    or, less desirably, by email). Fancier ways could involve a company
    having at least two certs, each signed by a different CA, ideally with
    each in a different jurisdiction (and with both CA jurisdictions outside
    the company's home one and ideally not too "cosy" with that home
    jurisdiction).

    Regards,

    PS I have simplified some cert aspects. For instance, most large
    companies will want a master cert which is only used to sign subsidiary
    company certs which are then used for day-to-day matters. This makes it
    much easier to, say, revoke a compromised subsidiary cert while still
    keeping the (better protected) master cert valid and able to issue a new
    replacement subsidiary cert.

    PPS Here's the CA security compromise I promised. It's so simple as to
    be laughable but the risk is still very real:

    All browswers (and the OS itself) keep a list of the credentials of all
    major CAs. It is child's play if one has even brief surreptitious access
    (< 1 minute) to someone's computer to swap that list for a list of one's
    own, a list with at least some "bogus" CA credentials. If the true user
    later signs on to a compromised website (phishing or whatever attack)
    those bogus CA credentials can be used to completely validate that https
    connection without so much as a murmur from the browser (key symbol will
    be there, etc.)
     
    nemo_outis, Mar 30, 2010
    #5
  6. nemo_outis

    Nomen Nescio Guest

    Nicely put and somewhat validates my origional arguement. I am
    in no way knowledgable in this field, but isn't there some way
    something could be put on a company website whereby you could
    validate the CA? Something like validating a file with an MD5
    checksum.

    > It would seem that the best protection against governmemt intrusion
    >> into certs is for companies to self issue their own certs and carry
    >> them to the cert companies.

    >
    >
    > I will answer you and afterwards I'll explain in a postscript a different
    > CA attack from the one in the articles that is very serious and very easy
    > to do!
    >
    >
    > As matters currently stand companies DO *generate* their own certs (or
    > call it a pre-cert if you will). The CAs (e.g., Verisign) merely
    > *digitally sign* those pre-certs (using as much or as little due
    > diligence as they see fit to confirm their provenance) thereby converting
    > them to "certified" certificates (to make a weak joke).
    >
    > Alternatively, a company (or other entity, such as you or me) can perform
    > *both* the generation and certifying roles - this results in a "self-
    > signed" certificate. Such a certificate effectively says: "I hereby
    > certify that I am me."
    >
    > Fortunately, there is no way to forge/spoof the company public/private
    > key part of either a CA-signed or self-signed certificate (without
    > breaching the original company's internal security); that part of the
    > protocol is rock-solid. The public/private keypair guarantees that an
    > entity, whether counterfeit or genuine, can at least be confirmed to be
    > the *same* entity at some later time. Any spoofing of an entity (even
    > one signed by a corrupt cert authority) must use different company keys
    > on the cert (that is, if the corrupt party expects to be able to decrypt
    > the SSL signon).
    >
    > Surprisingly, the self-signed certificate is the *best* type of
    > certificate *from a security standpoint* precisely because it does appear
    > so weak (a paradox, a paradox, a most ingenious paradox...). All
    > browsers will immediately flag such a "cert" for you rather than "rubber
    > stamp" it as OK and such a cert obviously requires further scrutiny if
    > the site involves any degree of trust in your dealings with it (which,
    > however, *isn't* always the case).
    >
    > So, how do you check out whether a self-signed cert is valid? There are
    > a number of methods but the short version is: By contacting the company
    > (or some other entity that is both trustworthy and knowledgable about the
    > company's cert) to confirm the validity of the company's cert.
    >
    > However, as they say in the late night TV ads, "But wait! There's more!"
    > You should contact the company (or other trustworthy entity) either
    > directly (i.e., face-to-face) or at least using an "out-of-band"
    > communication path (i.e., not the same as the initial one where you first
    > encountered the cert). But in this case you could have simply got the
    > cert here originally and not just as confirmation after getting it by a
    > less trustworthy path.
    >
    > Incidentally, the problem with using some "other trustworthy entity"
    > instead of the company itself is that that is exactly what the CA tried
    > to be (and failed). Except in special circumstances, why would you expect
    > some other entity performing a similar role (e.g., the repository in the
    > "perspectives" add-on) to be any better?
    >
    > So, while the self-signed cert is the *best* from a security standpoint,
    > it *stinks* from a usability standpoint. Besides being a PITA for you to
    > do this, few companies, except maybe some banks, are set up to handle it
    > (e.g., a telephone inquiry). Moreover, the website traffic would dwindle
    > to near nothing because most users would be neither capable nor willing
    > to go to such trouble.
    >
    > Probably the best from a compromise viewpoint for companies with at least
    > moderately skilled, privacy-conscious users (i.e, the 7 of us :) is to
    > have some automated out-of-band way of checking its cert (by telephone,
    > or, less desirably, by email). Fancier ways could involve a company
    > having at least two certs, each signed by a different CA, ideally with
    > each in a different jurisdiction (and with both CA jurisdictions outside
    > the company's home one and ideally not too "cosy" with that home
    > jurisdiction).
    >
    > Regards,
    >
    > PS I have simplified some cert aspects. For instance, most large
    > companies will want a master cert which is only used to sign subsidiary
    > company certs which are then used for day-to-day matters. This makes it
    > much easier to, say, revoke a compromised subsidiary cert while still
    > keeping the (better protected) master cert valid and able to issue a new
    > replacement subsidiary cert.
    >
    > PPS Here's the CA security compromise I promised. It's so simple as to
    > be laughable but the risk is still very real:
    >
    > All browswers (and the OS itself) keep a list of the credentials of all
    > major CAs. It is child's play if one has even brief surreptitious access
    > (< 1 minute) to someone's computer to swap that list for a list of one's
    > own, a list with at least some "bogus" CA credentials. If the true user
    > later signs on to a compromised website (phishing or whatever attack)
    > those bogus CA credentials can be used to completely validate that https
    > connection without so much as a murmur from the browser (key symbol will
    > be there, etc.)
     
    Nomen Nescio, Mar 30, 2010
    #6
  7. copy of some long-winded posts in another discussion group

    Law Enforcement Appliance Subverts SSL
    http://www.wired.com/threatlevel/2010/03/packet-forensics/

    from above:

    .... security researcher Chris Soghoian discovered that a small company
    was marketing internet spying boxes to the feds. The boxes were
    designed to intercept those communications -- without breaking the
    encryption -- by using forged security certificates,

    .... snip ...

    financial crypto blog discussion:

    Why the browsers must change their old SSL security (?) model
    http://financialcryptography.com/mt/archives/001232.html
    Pushing the CA into taking responsibility for the MITM
    https://financialcryptography.com/mt/archives/001233.html

    this is recent computer architecture blog (posting) discussing
    connection between supercomputing and electronic commerce:
    http://www.garlic.com/~lynn/2010f.html#56

    i.e. two of the people mentioned in the jan92 cluster scaleup meeting
    http://www.garlic.com/~lynn/95.html#13

    leave and show up at small client/server startup responsible for
    something called "commerce server". We are brought in as consultants
    because they want to do payments transactions on the server; the startup
    had also invented this technology they called "SSL" that they wanted to
    use. As part of mapping "SSL" to payment operations (now frequently
    called "electronic commerce"), required threat & vulnerability studies
    .... which included lots of assumptions about how SSL had to be deployed
    and used.

    As mentioned in the financial cryptography blog ... majority of exploits
    over the period since then ... have long been known.

    ...

    one of the references are to the large number of digital certificates
    for Certification Authorities that have been added to standard browser
    distributions over the years. In some cases, the original
    Certification Authorities have gone bankrupt and are no longer in
    business (browsers have no method for differentiating business
    practices of the increasing number of different Certification
    Authorities that have been enabled).

    one of the 20yr scenarios is criminal elements coming into some level
    of influence of any of these Certification Authorities. This is
    analogous to a number of situations where criminal elements were able
    to influence ATM cash machine manufacturing ... with skimming
    compromises installed at the time the machine was being built.

    A compromised Certification Authority is able to issue a digital
    certificate that is acceptable by every browser in the world ... for
    any business ... even for businesses that have digital certificates
    issued from totally different Certificate Authority.

    This is the old adage that the security trust chain is only as strong
    as the weakest link ... the criminal elements are likely to go after
    the weakest link not the strongest link ... (picking some clerk at a
    Certification Authority ... or a Certification Authority that has some
    other kind of weakness/vulnerability).

    From failure mode analysis ... having also done some number of
    high-availability products ... a high availability infrastructure is
    built so that the probability of infrastructure failure is the
    probability of all redundant components failing at the same time (the
    product/multiplication of the failure probabilities of the individual
    redundant components ... as the number of redundant components go up
    the probability of system failure decreases).

    However, the Certification Authority infrastructure is not a
    high-availability infrastructure .... its characteristic is the chain
    analogy ... the system fails if there is any failure in any component
    (basically adding the failure probability of each individual
    component) ... as the number of acceptable Certification Authorities
    increase ... the probability that there is an overall system failure
    increases (the inverse of high-availability operation where adding
    redundant components lowers the system failure risk).

    There is old post about jan92 meeting in ellisons conference room that
    draws a thread between high-availability cluster scaleup and current
    SSL "electronic commerce"
    http://www.garlic.com/~lynn/95.html#13

    Now, two of the people named in the above meeting, leave and show up
    at a small client/server startup responsible for something called
    "commerce server". As mentioned above ... we were then called in to
    consult because they wanted to do payment transactions on their
    server; the startup had also invented this technology they called
    "SSL" they wanted to use.

    another weak link in SSL domain name digital certificate infrastructure
    is the domain name system. When I apply for SSL digital certificate, I
    provide some information about who I am ... then the Certification
    Authority validates with the domain name infrastructure that I am also
    the true owner of the corresponding domain name.

    An exploit is domain name hijacking at the domain name system ... and
    then going to Certification Authority (that does the weakest validation)
    .... and apply for a valid SSL digital certificate.

    Countermeasures to domain name hijacking are using various technologies
    to improve the integrity of the domain name system. However, there is
    possibility that some of the technologies can also eliminate the need
    for SSL domain name certificates. I've pontificated about this catch-22
    in the past
    http://www.garlic.com/~lynn/subpubkey.html#catch22

    another article:

    Sneaking Into the Transport Layer With a Fake ID
    http://www.ecommercetimes.com/story/69636.html?wlc=1269788312

    If crooks can get into compromising POS terminal and ATM cash machines
    during manufacturing (with built in skimming devices, at one point there
    was an estimate that as many as 1/3rd of POS terminals being sold in
    particular market had built in skimming devices at manufacturing)
    .... what so unthinkable about crooks being able to obtain (valid) SSL
    digital certificates using forged identification.

    --
    42yrs virtualization experience (since Jan68), online at home since Mar1970
     
    Anne & Lynn Wheeler, Mar 30, 2010
    #7
  8. nemo_outis

    nemo_outis Guest

    Nomen Nescio <> wrote in
    news::

    > Nicely put and somewhat validates my origional arguement. I am
    > in no way knowledgable in this field, but isn't there some way
    > something could be put on a company website whereby you could
    > validate the CA? Something like validating a file with an MD5
    > checksum.


    Ah, but you forgot catch-22 :) How do you know you're looking at the
    *real* company website. After all, that's what the CA-signed certificate
    was supposed to ensure.

    If you're looking at a bogus counterfeit of the real site, it doesn't do
    much good if the bogus site has a page which says (complete with hashes,
    celebrity endorsements, whatever :) that its bogus certificate is OK.

    ***********

    However, here's another reason why self-signed certificates are not just
    "equivalent to" but actually "superior to" CA-signed certificates:

    Say, the first time you go to a site, you get its self-signed certificate
    and add it *permanently* to your browser store (Most browsers give you
    the option of adding it permanently or using it temporarily just one
    time). Your browser will have bitched and alerted you so it's your
    decision (and responsibility!) to have checked it out (or not) at that
    time. Let's pretend you were satisified that the site was legit (either
    because you really did do a separate telephone confirmation of its
    certificate - unlikely - or because the content and internal consistency
    of the site seemed satisfactory - pretty weak but by far the more likely
    case for all but the most diligent users). OK, you now have the site's
    self-signed cert in your browser store. And let's assume this really was
    the legit site.

    You are now in pretty good shape against some *subsequent* attempt to
    pass off a bogus site as that real site - your browser will alert you
    again if some other self-signed cert is used (such a bogus cert must
    *necessarily* have a *different key* even if all the other cert data
    (company name, etc.) is spoofed to appear correct.) [See PS for caveat]

    On the other hand, if the legit site had instead used a CA-signed cert,
    the first time you went to the site your browser would have (internally,
    no user interaction) checked that the company cert was indeed valid by
    checking it against the CA signing data the browser keeps in its store.
    The company cert would check out and so your browser would (seamlessly)
    let you access the site in https mode. However, the browser would NOT
    store the actual company cert. And there's the rub!

    The next time you go to (what is ostensibly) that site the browser will
    internally again perform the exact same checking routine to see if the
    CA-signed cert is valid (i.e., checks the cert out against the CA signing
    data the browser keeps in its internal store). But this time the
    (phised, etc.) site's CA-signed cert might be a bogus one (let's say
    government coerced). The false cert will pass muster - even if the new
    bogus cert has been signed by a different CA than the first time (even a
    CA in a different country). In other words, when a browser checks out a
    CA-signed cert, every time is the same as the first time - the browser
    has *no memory* of earlier approvals or on what they were based. And
    because it has no memory your browser will not "notice" that the signing
    CA has changed or that the company's key on the certificate has changed!

    In short, self-signed certs force the browser to "remember" them and so
    it is much easier to detect any subsequent changes (e.g., passing off
    attempts by a bogus site).

    However, the downside is that all this comes at the cost of convenience
    and usability. Sadly, faced with that tradeoff, most folks will sell
    their privacy and security for the mess of potage that is CA-signing.

    Regards,


    PS The caveat referred to above is this: I haven't checked what happens
    (i.e., what particular browsers do) if a site which originally used a
    self-signed certificate is found to use a CA-signed certificate on a
    subsequent visit. In principle the prowser has enough information to
    alert you to the change (which would save your ass in the unlikely but
    possible event that the new CA-signed cert is bogus). However, I
    strongly suspect (although I am too lazy and unmotivated to check) that
    most browsers would happily accept the new CA-signed cert without
    alerting you (after all, this is what the browser expects to be the
    common vanilla situation). In which case you're hooped!

    Unless... Maybe....

    The following depends on how particular browsers handle the case where a
    company cert is signed by a CA that is NOT in the browser's internal
    store (e.g., CACERT). (I haven't checked. I have the soul of a
    consultant: I theorize and report but leave actual implementation to
    others :)

    In such a case a browser WILL alert you - the question is what the
    browser does when you "approve" it using that site. What you (well, I
    :) want it to do is add the site's certificate to its internal store
    (just as for a self-signed cert). What you DON'T want the browser to do
    is to instead add the new CA to the internal browser store of valid CAs
    (where it could then be used to validate approve other sites, etc.) while
    not storing the site cert.

    If your browser handles things the "right" way then for maximum security
    you should purge your browser's internal store of *ALL* CA credentials
    (i.e., the internal list of valid CAs is the null set). This would force
    the browser to follow the self-signed drill (i.e., store the cert) for
    ALL sites, whether they use self-signed or CA-signed certs. A PITA but
    very secure.
     
    nemo_outis, Mar 30, 2010
    #8
  9. "nemo_outis" <> writes:
    > However, here's another reason why self-signed certificates are not just
    > "equivalent to" but actually "superior to" CA-signed certificates:


    re:
    http://www.garlic.com/~lynn/2010g.html#10 Gov't coerced Certs thwart SSL/TLS

    lots of past posts discussing SSL domain name certificates
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    note that Certification Authority digital certificate ... is simply a
    "self-signed" digital certificate that has been loaded into the browser
    cache of self-signed Certification Authority digital certificates (the
    primary difference between any random self-signed digital certificate
    and a Certification Authority self-signed digital certificate ... is
    whether or not the self-signed digital certificate has been loaded into
    the browser cache of Certification Authority self-signed digital
    certificates).

    the PKI-based digital certificate infrastructure is a chain of digital
    certificates that is rooted at the Certification Authority digital
    certification ... and it is a "root" because if is self-signed and
    loaded into browser Certification Authority digital certificate cache.

    As previously mentioned, the browser Certification Authority self-signed
    digital certificate caches have accumulated a large number of "root"
    certificates ... and browsers make no differentiation between the
    "roots". A compromised root could bring down the whole infrastructure by
    issuing "valid" certificates for any and all comers (even for entities
    that already have digital certificates from other roots).

    However, the nature of URLs have gotten quite obfuscated for a large
    percentage of the population ... so an attacker doesn't even necessarily
    have to even get a SSL digital certificate (for the original domain
    name) ... they can obtain a similar domain name (using a valid front
    company) and then obtain a valid SSL digital certificate. Then they send
    spam email asking people to click-on their URL (which has a valid
    SSL). They then set up their website to operate as a MITM (potentially
    using slightly modified standard proxy code) ... where they run two
    paird sessions ... one between the end-user and their proxy (using their
    SSL digital certificate) and a 2nd session with the "real" site (using
    that organization's SSL digital certificate). They are then able to
    evesdrop/skim all traffic and/or even modify traffic as necessary. This
    is slightly less privileged level than getting a valid SSL digital
    certificate for the original domain name (as opposed to just a similar
    domain name).

    Remember ... with the clicking convention and people paying little
    attention to the actual URL ... SSL primarily operates to validate that
    the webserver being talked to is the webserver (aka domain name) that it
    claims to be (not that the webserver that the user thinks they are
    talking to is the actual webserver that they are actually talking to).

    --
    42yrs virtualization experience (since Jan68), online at home since Mar1970
     
    Anne & Lynn Wheeler, Mar 30, 2010
    #9
  10. Nomen Nescio wrote:

    > Nicely put and somewhat validates my origional arguement. I am in no
    > way knowledgable in this field, but isn't there some way something could
    > be put on a company website whereby you could validate the CA?
    > Something like validating a file with an MD5 checksum.
    >


    That would just be adding complexity. Duplicating what's already in place
    with the certs themselves (the CA is essentially validating it's clients
    with an "MD5 hash").

    The solution to all this, as Nemo said, is self signed certs *and*
    education. Admins need to be educated with respect to *being* their own
    CA, and users need to learn to manage SSL certs more like they would a
    set of work keys.






    >> It would seem that the best protection against governmemt intrusion
    >>> into certs is for companies to self issue their own certs and carry
    >>> them to the cert companies.

    >>
    >>
    >> I will answer you and afterwards I'll explain in a postscript a
    >> different CA attack from the one in the articles that is very serious
    >> and very easy to do!
    >>
    >>
    >> As matters currently stand companies DO *generate* their own certs (or
    >> call it a pre-cert if you will). The CAs (e.g., Verisign) merely
    >> *digitally sign* those pre-certs (using as much or as little due
    >> diligence as they see fit to confirm their provenance) thereby
    >> converting them to "certified" certificates (to make a weak joke).
    >>
    >> Alternatively, a company (or other entity, such as you or me) can
    >> perform *both* the generation and certifying roles - this results in a
    >> "self- signed" certificate. Such a certificate effectively says: "I
    >> hereby certify that I am me."
    >>
    >> Fortunately, there is no way to forge/spoof the company public/private
    >> key part of either a CA-signed or self-signed certificate (without
    >> breaching the original company's internal security); that part of the
    >> protocol is rock-solid. The public/private keypair guarantees that an
    >> entity, whether counterfeit or genuine, can at least be confirmed to be
    >> the *same* entity at some later time. Any spoofing of an entity (even
    >> one signed by a corrupt cert authority) must use different company keys
    >> on the cert (that is, if the corrupt party expects to be able to
    >> decrypt the SSL signon).
    >>
    >> Surprisingly, the self-signed certificate is the *best* type of
    >> certificate *from a security standpoint* precisely because it does
    >> appear so weak (a paradox, a paradox, a most ingenious paradox...).
    >> All browsers will immediately flag such a "cert" for you rather than
    >> "rubber stamp" it as OK and such a cert obviously requires further
    >> scrutiny if the site involves any degree of trust in your dealings with
    >> it (which, however, *isn't* always the case).
    >>
    >> So, how do you check out whether a self-signed cert is valid? There
    >> are a number of methods but the short version is: By contacting the
    >> company (or some other entity that is both trustworthy and knowledgable
    >> about the company's cert) to confirm the validity of the company's
    >> cert.
    >>
    >> However, as they say in the late night TV ads, "But wait! There's
    >> more!" You should contact the company (or other trustworthy entity)
    >> either directly (i.e., face-to-face) or at least using an "out-of-band"
    >> communication path (i.e., not the same as the initial one where you
    >> first encountered the cert). But in this case you could have simply
    >> got the cert here originally and not just as confirmation after getting
    >> it by a less trustworthy path.
    >>
    >> Incidentally, the problem with using some "other trustworthy entity"
    >> instead of the company itself is that that is exactly what the CA tried
    >> to be (and failed). Except in special circumstances, why would you
    >> expect some other entity performing a similar role (e.g., the
    >> repository in the "perspectives" add-on) to be any better?
    >>
    >> So, while the self-signed cert is the *best* from a security
    >> standpoint, it *stinks* from a usability standpoint. Besides being a
    >> PITA for you to do this, few companies, except maybe some banks, are
    >> set up to handle it (e.g., a telephone inquiry). Moreover, the website
    >> traffic would dwindle to near nothing because most users would be
    >> neither capable nor willing to go to such trouble.
    >>
    >> Probably the best from a compromise viewpoint for companies with at
    >> least moderately skilled, privacy-conscious users (i.e, the 7 of us :)
    >> is to have some automated out-of-band way of checking its cert (by
    >> telephone, or, less desirably, by email). Fancier ways could involve a
    >> company having at least two certs, each signed by a different CA,
    >> ideally with each in a different jurisdiction (and with both CA
    >> jurisdictions outside the company's home one and ideally not too "cosy"
    >> with that home jurisdiction).
    >>
    >> Regards,
    >>
    >> PS I have simplified some cert aspects. For instance, most large
    >> companies will want a master cert which is only used to sign subsidiary
    >> company certs which are then used for day-to-day matters. This makes
    >> it much easier to, say, revoke a compromised subsidiary cert while
    >> still keeping the (better protected) master cert valid and able to
    >> issue a new replacement subsidiary cert.
    >>
    >> PPS Here's the CA security compromise I promised. It's so simple as
    >> to be laughable but the risk is still very real:
    >>
    >> All browswers (and the OS itself) keep a list of the credentials of all
    >> major CAs. It is child's play if one has even brief surreptitious
    >> access (< 1 minute) to someone's computer to swap that list for a list
    >> of one's own, a list with at least some "bogus" CA credentials. If the
    >> true user later signs on to a compromised website (phishing or whatever
    >> attack) those bogus CA credentials can be used to completely validate
    >> that https connection without so much as a murmur from the browser (key
    >> symbol will be there, etc.)
     
    Dave U. Random, Mar 30, 2010
    #10
  11. nemo_outis

    nemo_outis Guest

    Anne & Lynn Wheeler <> wrote in
    news::

    ....
    Good points.

    Regards,
     
    nemo_outis, Mar 30, 2010
    #11
    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. James

    TLS, SSL, SSH

    James, Mar 22, 2005, in forum: Computer Support
    Replies:
    5
    Views:
    19,536
    Charles Blake
    May 7, 2007
  2. Melic

    SSL or TLS?

    Melic, Oct 4, 2006, in forum: Computer Security
    Replies:
    0
    Views:
    434
    Melic
    Oct 4, 2006
  3. Rob Slade, doting grandpa of Ryan and Trevor

    REVIEW: "SSL and TLS: Theory and Practice", Rolf Oppliger

    Rob Slade, doting grandpa of Ryan and Trevor, Jul 8, 2010, in forum: Computer Security
    Replies:
    0
    Views:
    1,482
    Rob Slade, doting grandpa of Ryan and Trevor
    Jul 8, 2010
  4. RichA

    Native Indians try to thwart photographer rights

    RichA, Nov 4, 2011, in forum: Digital Photography
    Replies:
    85
    Views:
    1,331
    John Turco
    Nov 12, 2011
  5. John A.

    Re: Native Indians try to thwart photographer rights

    John A., Nov 9, 2011, in forum: Digital Photography
    Replies:
    2
    Views:
    334
    John A.
    Nov 9, 2011
Loading...

Share This Page